\section{Daten Sicherheit \it \bfseries \tiny JR}\label{sec:datensicherheit}
Cloud Computing ist eines der großen Themen der letzten Jahre. Dies wird sich auch in Zukunft so
schnell nicht ändern. Immer mehr Firmen drängen in die Cloud. Daher ist die Datensicherheit
innerhalb der Cloud ein entscheidendes Kriterium. Nicht nur in Bezug auf die Frage, welche Daten
in der Cloud gespeichert werden können, sondern auch im Hinblick auf die Auswahl des Cloud Service
Providers (CSP). Ein weiterer entscheidender Faktor bezüglich der Datensicherheit sind die drei
Service-Modelle des Cloud Computing: SaaS, PaaS und IaaS. Weiter spielen auch die vier Deployment
Modelle, Public, Private, Hybrid und Community Cloud, eine nicht unwesentliche Rolle für die
Datensicherheit.
Abhängig von diesen Modellen fällt die Verantwortung für die Sicherheitsmaßnahmen der Daten auf den
Dateneigentümer, den CSP oder geteilt an beide.
Datensicherheit ist folglich eines der zentralen Themen des Cloud Computing und es umfasst mehr als
einfache Datenverschlüsselung. Auch wenn vielfach bekannte und erprobte Sicherungsmechanismen zum
Tragen kommen. Denn so ist beispielweise zu unterscheiden zwischen ruhenden Daten (Data at Rest) und
bewegten Daten (Data in Motion). Diese Daten müssen verschieden betrachtet werden und bedürfen
unterschiedlicher Maßnahmen zur Wahrung der Sicherheit.
Datenverschlüsselung ist also eine Kernkomponente auch bei Cloud Security. Aber auch hier gilt, die
beste Verschlüsselung ist wertlos, wenn die Schlüssel nicht sicher sind oder aber die Endpunkte 
unsicher sind. Abhängig vom Service und Deployment Model der Cloud, liegt die Verantwortung für die
Sicherung dieser Endpunkte beim CSP oder beim  Kunden.

\subsection{Sicherheitsbedenken der Cloudnutzer}\label{sec:datensicherheit:sicherheitsbedenkenDerCloudnutzer}
Es sind bei der Nutzung einer Cloud folglich viele Dinge in Bezug auf die Sicherheit zu beachten.
Daher ist es also verständlich, dass Firmen Sicherheitsbedenken haben Daten in der Cloud zu
speichern und sensible Daten in einer Public, Hybrid oder sogar in einer Community Cloud zu
verwenden.
Verglichen mit der firmeninternen Datenspeicherung bestehen die Bedenken vor allem in Bezug auf
folgende zwei Punkte:

\begin{itemize}
  \item Verlust der Kontrolle "uber die Daten, wenn sie nicht mehr im eigenen Netz liegen.
  \item Gefahr der sensiblen Daten durch eine öffentliche Cloud, da die Daten von verschiedenen
  Firmen in einer Cloud liegen können. Somit bestehen bedenken der Abschottung der eigenen Daten
  gegenüber den Daten der anderen CSP-Kunden.
\end{itemize}

Im Vergleich zur Nutzung einer Public Cloud bietet die physikalische Kontrolle über die Daten, also
die Verwendung eines firmeninternen Datenzentrums und die Verarbeitung auf rein lokalen Computern
möglicherweise Vorteile im Hinblick auf die Sicherheit. Dies ist aber nicht immer der Fall.
Denn Tatsache ist, das viele Unternehmen zwar bemüht sind hohe Sicherheitsstandards durchzusetzen,
jedoch oft nicht qualifiziert sind in dem Bereich der Informationssicherheit noch ist es ihr
Geschäftbereich. Folglich ist Sicherheit oft eine gewünschte Eigenschaft. Da die Fachkenntnis
über Sicherheit selten die Kernkompetenz von Computeranwendern in Unternehmen ist, bleibt die
Sicherheit oft eine gewünschte Eigenschaft und wird nicht Realität.
Folglich bedeutet dies:
\begin{itemize}
  \item Die Verschiebung der Datenspeicherung in die Cloud muss nicht zwangsweise neue
  oder erhöhte Risiken für die Datensicherheit bedeuten, sondern kann sogar die Sicherheit
  erhöhen.
  \item Das Anvertrauen der Daten an einen externen Dienstleister kann zu erhöhter Datensicherheit
  führen und Kosteneffektiver sein.
\end{itemize}

Denn die Cloud Service Provider müssen zertifiziert sein, d.h., es ist sichergestellt das bestimmte
Standards in Bezug auf Sicherheit erfüllt sein müssen. Somit ist oftmals ein höheres Maß an
Sicherheit geboten, als es bei firmeninterner Datenhaltung der Fall ist.
Ein weiterer Punkt ist, dass Firmen zwar Bedenken über die Sicherheit ihrer Daten haben, aber oft im
Falle eines Disasters, externe spezialisierte Dienstleister für Disaster-Recovery in Anspruch
nehmen. Ein weiteres Beispiel wäre die Inanspruchnahme eines Dienstleisters für die sichere
Vernichtung sensibler Daten. In beiden Fällen geben sie die Kontrolle über die sensiblen Daten an
externe Dienstleister ab. Somit vertrauen sie ihre Daten externen Unternehmen an. Nichts anderes ist
die Verwendung einer Cloud-Umgebung.

Andererseits gibt es auch Daten, die zu sensibel sind um sie in einer Public Cloud zu speichern.
Solche hochsensiblen Daten sind beispielsweise Daten betreffend der nationalen Sicherheit.
Folglich sind die geforderten Sicherheitskriterien höher als die, welche ein Cloud Provider
bieten kann. Technisch gesehen wäre es möglich eine Hochsicherheits Cloud umzusetzen. Der
ausschlaggebende Faktor sind die extremen Kosten, die eine solche Hochsicherheitscloud mit sich
bringt würde, die eine Umsetzung verhindern.
Es ist daher nicht ausgeschlossen, dass in Zukunft solche Hochsicherheitscloudumgebungen angeboten
werden.

In jedem Fall ist es abhängig von den Daten und ihren Sicherheitsanforderungen, was für ein
Cloud-Modell für ihre Speicherung angebracht ist. Wie die Abbildung
\ref{figure:SicherheitsbedurfnisseCloudumgebungen} zeigt, sensible/regulatorische Daten
beispielsweise in einer Community oder Private Cloud-Umgebung, also in einer Cloud-Umgebung
verwaltet durch die eigene Firma oder aber eine Community Cloud, d.h. eine Cloud-Umgebung, die sich
Partnerfirmen teilen.

\begin{figure}[h]
\centering{
\scalebox{0.9}{\includegraphics{./img/fig5_1.jpg}}}
\caption[Sicherheitsbedürfnisse: Public, Community und Private Cloud]{Sicherheitsbedürfnisse:
Public, Community und Private Cloud. Aus: \cite{winkler-seccloud-11}}
\label{figure:SicherheitsbedurfnisseCloudumgebungen}
\end{figure}

\subsection{Organisatorische Verantwortlichkeiten - Eigent"umer und
Verwalter}\label{sec:datensicherheit:Organisatorische Verantwortlichkeiten Eigentumer und Verwalter}
Unabhängig davon, ob ein Cloudservice genutzt wird oder nicht, ist es wichtig, über ein Backup zu
verfügen. Es sollten immer zwei Backupkopien vorhanden sein, die nicht an der gleichen Stelle
lagern, so dass wenn eine Schaden nehmen sollte, die andere Kopie nicht betroffen ist.
Dies muss auch bei der Verwendung eines Clouddienstes der Fall. Oft wird eine angemessene
Datensicherung durch den Dateneigentümer bei Clouddienstverwendung nicht mehr praktiziert, oder es
besteht der Irrglaube, die Datensicherung durch den CSP sei eine einklagbare Anforderung und somit
nicht mehr selbst durchzuführen. Dies ist stark abhängig von den verschiedenen Service-Modellen
einer Cloud-Umgebung. Wenn Daten in einer Cloud gespeichert werden, so liegt die Verantwortung für
die Sicherung teilweise beim CSP als Verwalter der Daten, bei Platform as a Service (PaaS) oder
aber komplett, bei Software as a Service (SaaS). Bei geteilter Verantwortung gibt der Eigentümer
also nicht die Verantwortung für die Datensicherheit ab, sondern muss Gewissenhaft dafür Sorgen,
dass seine Daten durch den Verwalter korrekt gesichert werden.
Die Abbildung \ref{figure:Eigentumer Kontrolle uber Daten} zeigt, dass ein Eigentümer davon
profitieren kann, dass bei SaaS die Verantwortung und Kontrolle bei dem CSP liegt. Weiter zeigt die
Abbildung das der Eigentümer zunehmend verantwortlich ist beginnend mit PaaS und steigend mit IaaS.
Die zunehmende Verantwortung für den Eigentümer erfordert aber auch, das nötige Vorhandensein
erheblicher Security-Kompetenz, um entsprechende Datensicherheit zu gewährleisten.
Generell gibt es zwei Stadien der Daten, in denen die Daten in einer Cloud-Umgebung gefährdet sind:
ruhende Daten (data at rest), Daten, die in einer Cloud gespeichert sind, und bewegte Daten (data
in motion), Daten auf dem Weg in oder aus der Cloud.

\begin{figure}[h]
\centering{
\scalebox{0.9}{\includegraphics{./img/fig5_2.jpg}}}
\caption[Zunahme der Kontrolle über die Daten durch den Eigent"umer von Saas
bis IaaS]{Zunahme der Kontrolle über die Daten durch den Eigent"umer von Saas
bis IaaS. Aus: \cite{winkler-seccloud-11}}
\label{figure:Eigentumer Kontrolle uber Daten}
\end{figure}


\subsection{Data at Rest}\label{sec:datensicherheit:data at rest}
Wie bereits erwähnt unterscheidet man die Daten nach Zustand, und auch die Maßnahmen zur Umsetzung
der Datensicherheit unterscheiden sich je nach Zustand.
Unter dem Begriff Data at Rest, also ruhende Daten, werden alle Daten verstanden, die im
Computerspeicher liegen, jedoch ohne die Daten, die über ein Netzwerk übertragen werden oder zum Lesen oder
Aktualisieren vorläufig im Computerspeicher residieren.
Ruhende Daten können folglich Archive oder Referenzdateien sein, die selten oder
nie geändert werden. Aber auch Daten, die regelmäßig aber nicht ständig geändert werden,
sind ruhende Daten. Beispiele dafür sind wichtige Unternehmensdateien, die auf der
Notebookfestplatte eines Mitarbeiters gespeichert werden, Dateien auf externen
Datensicherungsmedien, Dateien auf den Servern eines Speichernetzwerks (Storage Area Network – SAN)
oder Dateien auf den Servern eines externen Datensicherungs-Providers.
Folglich ist es egal, ob es sich um die Daten auf einem Mitarbeiter-PC, einem Firmenserver oder aber
die Daten auf einem Backupsystem handelt, all dieses sind Daten die unter den Zustand Data at Rest
fallen.
Unternehmen, Behörden und andere Organisationen machen sich Sorgen um die stets gegenwärtige
Bedrohung der ruhenden Daten durch Hacker. Um die ruhenden Daten vor dem Zugriff, dem Diebstahl oder
der Änderung durch Unbefugte zu schützen, werden oft Sicherheitsmaßnahmen wie Datenverschlüsselung
und hierarchischer Passwortschutz eingesetzt. Für manche Datentypen sind bestimmte
Sicherheitsmaßnahmen sogar per Gesetz vorgeschrieben.
Dies gilt unabhängig von dem Speicherort der Daten, also ob in der Cloud oder Firmen intern.
Daher unterscheiden sich auch die Maßnahmen für die Umsetzung der Sicherheit von ruhenden Daten in
einer Cloud nicht von denen einer Firmen internen Speicherung. Wie in dem vorangegangenen
Abschnitt erläutert, entsteht bei der Speicherung in einer Cloud ein Risiko dadurch, dass der
Eigentümer nicht mehr physikalisch die Kontrolle über die Daten hat. Vorteil davon wiederum wie
bereits erwähnt, das Profitieren durch die Sicherheitskompetenz des Cloud Service Providers und
möglicherweise Vorteile in Bezug auf die Sicherheit gegenüber der Firmen internen Speicherung.
Wie in Abbildung \ref{figure:SicherheitsbedurfnisseCloudumgebungen} gezeigt, je weniger Kontrolle
der Eigentümer hat --  von der Private Cloud abnehmend bis zur Public Cloud --, desto größer die
Sorge um die Sicherheit und das Vertrauen in den CSP, dass die eingesetzen Mechanismen zur
Gewährleistung der Datensicherheit effektiv und dem Level der Datensensibilität angepasst sind. Die
Abbildung \ref{figure:Eigentumer Kontrolle uber Daten} zeigte aber, dass die Verantwortung des
Eigentümers für die Sicherheit der Daten zu sorgen steigt, ausgehend von SaaS zu PaaS und weiter zu
IaaS.
Eine Voraussezung für die Verwendung eines externen Cloud Providers ist also, dass ein gewisses
Risiko akzeptabel ist. Dieses Risiko ist abhängig zum einen von den verschiedenen Cloud Service
Modellen, aber auch von dem Deployment Modell einer Cloud.

Ein weiterer wichtiger Punkt ist, den Markt der Cloud Service Provider zu analysieren und zu
vergleichen, was die einzelnen Provider im Speziellen für Features bieten. Gerade im Hinblick auf
offizielle Zertifizierungen und Standards zur Gewährleistung von Sicherheit, die ein CSP erfüllt.
Dabei ist es natürlich, das Serviceanbieter mit höheren Sicherheitsstandards auch höhere
Kosten verursachen. Folglich muss der Kunde anhand seiner Daten abwägen, welche Standards erfüllt
sein müssen und somit die Auswahl eines Anbieters dementsprechend treffen.



\subsection{Data in Motion}\label{sec:datensicherheit:data in motion}
Data in Motion, bewegte Daten, sind Daten zum Zeitpunkt ihres Transports übers Netzwerk oder ein
anderes Medium, also der Zustand während des Übergangs, beispielsweise einer Datei oder eines
Datenbankeintrages in eine andere Form, an dem gleichen oder einem anderen Ort. Eine Datei, die in
die Cloud gespeichert wird, ist folglich immer während des Zeitpunkts des Uploads als Daten in
Bewegeung (data  in motion) anzusehen. Solche Daten sind nicht immer Daten, die zu ruhenden Daten
werden, also Daten die permanent gespeichert werden. Der Benutzername und das Passwort zur Anmeldung
an einer Website sind beispielweise solch sensible Daten, die nicht dauerhaft in
unverschlüsselter Form gespeichert werden.
Da bewegte Daten nur während der Übertragung zwischen Punkten existieren -- wie im Arbeitsspeicher
(RAM) oder zwischen Endpunkten --, beruht die Sicherung dieser Daten darauf, sie vor Manipulation zu
schützen, also ihre Vertraulichkeit zu gewährleisten.
Denn die größte Gefahr geht davon aus, dass die Daten abgefangen und verändert werden.Benutzernamen
und Passworter sollten folglich nie ungeschützt über ein Netzwerk übertragen werden, da sie
abgefangen und genutzt werden könnten.
Beispielsweise indem jemand anderes sich als Sie ausgibt und so Zugriff auf sensible Informationen
erhält. Andere private Informationen wie Bankkonto-Informationen sollten auch nur geschützt über
ein Netzwerk übertragen werden. Folglich ist die Lösung, die Nutzung einer verschlüsselten
Verbindung. Somit braucht man sich dann keine Sorgen mehr um die Sicherheit der Daten während der
Übertragung zu machen.
Daten in Bewegung sind ungeschützt besonders anfällig für Angreifer und somit sicherheitskritisch,
da der Angreifer nicht in der Nähe des Computers sein muss, auf dem die Daten gespeichert
sind, sondern er muss nur irgendwo auf dem Weg der Daten Zugang zu ihnen bekommen.
Ein weiterer kritischer Punkt in Bezug auf die Datensicherheit während der Übertragung ist, dass
nicht sicher ist, was alles mit ihnen in dieser Zeit passiert. So können die Datenpakete
beispielsweise während des Transports an Zwischenstationen gecached werden, oder Endpunkte legen
temporäre Dateien an, die dann nicht gesichert sind. Folglich gibt es keine bessere Lösung, um die
Sicherheit zu gewährleisten, als die Daten während des Transports zu verschlüsseln.

\subsection{Datenverschl"usselung}\label{sec:datensicherheit:Datenverschl"usselung}
Nachdem nun erläutert wurde welche Arten von Daten in Bezug auf Sicherheit beim Cloud Computing
unterschieden werden, wird nun darauf eingegangen, wie diese zu sichern sind.
Der bester Ansatz um die Sicherheit von Daten zu gewährleisten, ist die Beschränkung des Zugangs zu
den Daten. Dies wird durchgesetzt durch den Prozess der Authentifizierung und Autorisierung.
Ein Benutzer sollte also immer nach seinen Authentisierungsinformationen gefragt werden und
erst dann Zugriff entsprechend seiner gesetzten Zugriffsrechte auf Daten erhalten. Somit ist
sichergestellt, dass er nur Operationen auf den Daten ausführen kann, die ihm explizit zugeteilt
wurden. Wenn die Daten, auf die zugegriffen werden soll, lokal auf dem Computer liegen, ist die
Zugriffskontrolle einfach zu realiseren durch das Dateisystem des Computers. Handelt es sich jedoch
um Daten auf einem Server, auf die von einem entfernten Client zugegriffen wird, beispielsweise
über Protokolle wie NFS, CIFS, HHTP oder FTP, so müssen die Zugangsberechtigungen sicher über das
Netzwerk transportiert werden. In diesem Fall werden daher Protokolle verwendet, die eine sichere,
also verschlüsselte Kommunikation ermöglichen, wie SSL (Secure Sockets Layer), TLS (Transport Layer
Security) oder IPSEC (Secure Internet Protocol).


\subsubsection{"Uberblick Kryptographischer Techniken}\label{sec:datensicherheit:daten
verschlusselung:uberblick kryptographischer techniken}
Verschlüsselung der Daten ist in einer Cloud-Umgebung die Maßnahme, um Datensicherheit zu
gewährleisten. Es ist aber ein komplexes Thema und so ist es auch wichtig, dass sie korrekt
angewendet wird, damit sie auch die erwartete Sicherheit gewährleistet.
Heutzutage dient die Kryptographie nicht mehr nur der Sicherstellung von Vertraulichkeit, sondern
sie bietet auch Techniken zur Sicherstellung von Integrität, Authentifizierung und digitaler Signaturen.
Um wirksam die Vertraulichkeit von Daten zu gewährleisten, wird Klartext mittels kryptographischer
Verfahren in verschlüsselten Text überführt. Dies basiert immer auf mathematischen Funktionen die
verschiedene Kriterien erfüllen müssen:
\begin{itemize}
  \item Der Algorithmus und seine Implementierung  muss schnell und effizient sein bei der
  Umwandlung von Klartext zu verschlüsseltem Text.
  \item Der Algorithmus muss öffentlich zugänglich sein und von kryptograpfischen Experten
  untersucht sein, um seine Sicherheit zu gewährleisten. 
  \item Der Algorithmus muss Brute-Force-Angriffen standhalten.
\end{itemize}
Unterschieden werden kryptographische Verfahren nach ihrer Funktionsweise, in symmetrische
Verschlüsselung, ein Schlüssel zum Ver- und Entschlüsseln, und asymmetrische Verschlüsselung, zwei
verschiedene Schlüssel zum Ver- und Entschlüsseln.

\paragraph{Symmetrische Verschlüsselung} $\;$ \\
Bei der symmetrische Verschlüsselung werden, wie schon erwähnt, für das Ver- und Entschlüsseln
jeweils derselbe Schlüssel verwendet (Abbildung \ref{figure:symmetrische Verschlusselung}). Die
symmetrische Verschlüsselung hat ein breites Anwendungsfeld, aber wenn sie für die Verschlüsselung
einer Kommunikation zwischen mehreren Endpunkten genutzt wird, kann das Schlüssel\-ma\-nage\-ment sehr
komplex werden. Denn jeder Kommunikationspartner muss den Schlüssel kennen. Das Problem dabei
ist, diesen auszutauschen, ohne einen sicheren Kanal zu haben, daher die Komplexität des
Schlüsselmanagements.

\begin{figure}[h]
\centering{
\scalebox{0.9}{\includegraphics{./img/fig5_4_symmetric.jpg}}}
\caption[Symmetrische Verschlüsselung]{Symmetrische Verschlüsselung. Aus: \cite{winkler-seccloud-11}}
\label{figure:symmetrische Verschlusselung}
\end{figure}



\paragraph{Asymmetrische Verschlüsselung} $\;$ \\
Die asymmetrische Verschlüsselung, auch bekannt als public-private Key-Verschlüsselung, nutzt im
Gegensatz zur symmetrischen Verschlüsselung zwei verschiedene Schlüssel, also für die Ver- und
Entschlüsselung jeweils einen anderen. Der Schlüssel zum Verschlüsseln (Public-Key) ist
unterschiedlich, aber mathematisch in Beziehung stehend zu dem Schlüssel fürs Entschlüsseln
(Private-Key) (Abbildung \ref{figure:symmetrische Verschlusselung}). Der primäre Vorteil des
asymmetrische Verschlüsselungsverfahrens ist, dass nur der private Schlüssel geheim gehalten werden
muss -- der öffentliche Schlüssel kann veröffentlich werden, ist also, wie der Name schon sagt,
öffentlich zugänglich. Auch wenn die beiden Schlüssel mathematisch gesehen in einer Beziehung stehen
und so eine Abhängigkeit unter ihnen besteht, so ist es dennoch heutzutage nicht möglich mit
endlichem Aufwand aus dem öffentlichen Schlüssel den privaten zu errechnen.
Das Public-Private Key-Verfahren bietet in dem Cloud Computing Umfeld eine gute Möglichkeit, um
Vertraulichkeit zu gewährleisten, nicht nur in Bezug auf Datenverschlüsselung. Es kann auch genutzt
werden, um einen Benutzer oder einen technischen Endpunkt (bsp. einen Server) zu authentifizieren
oder aber auch um einen sicheren Verbindungskanal zwischen zwei Kommunikationspartnern zu
initiieren.

\begin{figure}[h]
\centering{
\scalebox{0.9}{\includegraphics{./img/fig5_4_asymmetric.jpg}}}
\caption[Asymmetrische Verschlüsselung]{Asymmetrische Verschlüsselung. Aus: \cite{winkler-seccloud-11}}
\label{figure:asymmetrische Verschlusselung}
\end{figure}

\subsubsection{Fehler in Bezug auf Datenverschl"usselung}\label{sec:datensicherheit:daten
verschlusselung:fehler in bezug auf datenverschl"usselung}
Kryptographie ist heutzutage weit verbreitet, und auch für Endanwender leicht zu\-gäng\-lich, um Daten
auf lokalen oder entfernten Datenträgern zu verschlüsseln oder die Kommunikation zu sichern.
Aber so verbreitet die Kryptographie auch ist, sie wird oft nicht genutzt, implementiert wenn es
nötig wäre oder sie wird in unsichererweise bzw. ineffektiv genutzt.
Ein Beispiel, das die ineffektive Nutzung von Kryptographie verdeutlicht, ist: die Nutzung von 
Kryptographie zur sicheren Kommuikation und Authentifizierung mit einem Internet-Service von einem
PC, der nicht  die aktuellsten Security Patches eingespielt hat oder anderweitig kompromittiert ist.
In einem solchen Fall hat der Einsatz von starker Kryptographie den gleichen Effekt in Bezug auf
Sicherheut wie die Anbringung einer Tresortür an einen Pappkarton.

Beispiele für fehlerhaften Nutzung von Kryptographie:
\begin{itemize}
  \item Nicht nutzen von kryptografischen Verfahren, obwohl sie angeboten werden.
  \item Verwendung von unsicheren Protokollen wie HTTP, FTP oder Telnet, obwohl ihre sicheren
  Pendants, HTTPS, SFTP, SSH, verfügbar sind.
  \item Speichern eines Passworts oder Klartext Private-Keys in einer Binär-Datei,
  Konfigurationsdatei oder in einer versteckten Datei (wie bsp. eine durch einen vorangestellten
  Punkt versteckte Datei unter Linux).
  \item Der Überzeugung sein, selbst einen sicheren Algorithmus implementieren zu können anstatt
  verfügbare und analysierte zu verwenden.
  \item Senden von sensiblen Daten, wie Passwörtern, PINs oder anderen Zugangsdaten, in einer
  unverschlüsselten E-Mail.
\end{itemize}

Es gibt also viele Dinge, die in Bezug auf die korrekte Anwendung von Kryptographie beachtet werden
müssen. Die hier genannten Beispiele zeigen nur einen kleinen Ausschnitt der Fehler, die in Bezug
auf die Nutung gemacht werden können.

\subsection{Authentifikation und Identit"aten}\label{sec:datensicherheit:Authentisierung und
Identitaten}
Die Erhaltung der Vertraulichkeit, Integrität und Verfügbarkeit von Daten ist eine
Funktion von korrekt eingesetzten Programmen und korrekter Konfiguration, System- und
Programmsicherheitsmechanismen auf verschiedenen Schichten in der Cloud Infrastruktur.
Eine wichtige Rolle spielt hierbei das Authentifikations und Intentitäts-Management.
Die Authentisierung von Benutzern oder auch anderen Kommunikationssystemen kann auf
unterschiedliche Arten erfolgen, aber sie basiert immer auf Krypographie. Die Authentifizierung
basiert immer auf einer Kombination von Authentifizierungs-Faktoren: etwas, dass ein Individuum weiß
(z.B. ein Passwort), etwas, dass es besitzt (wie z.B. ein Sicherheits-Token), oder
eine messbare Qualität, die untrennbar mit ihm verbunden ist (wie z.B. ein Fingerabdruck).
Die Grundlage für jede Authentifikation bildet eine zugrunde liegende Identitätsinfrastruktur.
Die einfachste Regelung ist die Speicherung der Account-Informationen für einen oder eine
kleine Anzahl von Benutzern in flachen Dateien, die verwendet werden, um die Identität und
Passwörter zu überprüfen. Aber dieses Vorgehen ist nur für sehr kleine Systeme geeignet, denn es
scaliert nicht gut, ist somit aufwendig in der Wartung. Das generelle Intentitätsmangement ist
aber nicht Ziel dieser Ausarbeitung und daher wird nicht weiter darauf eingegangen. Im
Folgenden werden verschiedene Zugriffskontrolltechniken erläutert.

Zugriffskontrollmechanismen sind ein entscheidendes Mittel, um in einer komplexen IT-Infrastruktur
zuverlässig die Trennung und Integrität der verschiedenen Ebenen oder Kategorien von Informationen
der verschiedenen Parteien umzusetzen.
Bei der Zugriffskontrolle geht es um Subjekte, die bestimmte Rechte besitzen, um auf gegebenen
Objekten Aktionen entsprechend ihren Zugriffsrechten durchführen zu dürfen.
Zugriffskontrollmechanismen beziehen sich also auf:
\begin{itemize}
  \item \textbf{Subjekte} Menschen oder Prozesse, die in ihrem Namen handeln.
  \item \textbf{Objekte} Dateien oder andere Ressourcen (ein Verzeichnis, ein Gerät oder eine
  Dienstleistung).
\end{itemize}

Die verbreitesten Zugriffskontrollmodelle sind (Abbildung \ref{figure:Zugriffskontrollmodelle}):
\begin{description}
\item[Discretionary Access Control (DAC):] Die Entscheidung, ob auf eine Ressource zugegriffen
werden darf, wird allein auf der Basis der Identität des Akteurs getroffen. Dies bedeutet, die
Zugriffsrechte für (Daten-)Objekte werden pro Benutzer festgelegt. Jedes Objekt hat also einen
Besitzer und dieser legt fest, welcher Nutzer auf seine Objekte zugreifen darf. Folglich kann die
Verwaltung der Zugriffsrechte sehr kompliziert werden je größer die Anzahl der Nutzer und Objekte
wird.
\item[Role Based Access Control (RBAC):] Den Benutzern werden Rollen zugeordnet. Benutzer können
dabei mehrere Benutzerrollen besitzen. An eine Rolle sind beispielsweise 1 bis n
Gruppenzugehörigkeiten gebunden. Je nach Rollenzuordnung des Benutzers (und den damit verbundenen
Gruppenzugehörigkeiten) erteilt oder sperrt das System dann das Zugriffsrecht auf Ressourcen. Häufig
werden vor allem Lesen, Schreiben und Ausführen von Dateien mittels RBAC kontrolliert; das Verfahren
ist jedoch nicht darauf beschränkt.
\item[Mandatory Access Control (MAC):] Die Entscheidungen über Zugriffsberechtigungen werden nicht
nur auf der Basis der Identität des Akteurs (Benutzers, Prozesses) und des Objekts (Ressource, auf
welche zugegriffen werden soll) gefällt, sondern aufgrund zusätzlicher Regeln und Eigenschaften (wie
Kategorisierungen, Labels und Code-Wörtern). Im Unterschied zu anderen Zugriffsmodellen wie DAC oder
RBAC werden spezielle Funktionen in das IT-System und die Anwendungsprogramme eingearbeitet, welche
den Zugriff, die Benutzung und Konvertierung von Informationen nur unter den im jeweiligen Konzept
geltenden Voraussetzungen erlauben. 
\end{description}

\begin{figure}[h]
\centering{
\scalebox{0.9}{\includegraphics{./img/fig5_5.jpg}}}
\caption[Zugriffskontrollmodelle]{Zugriffskontrollmodelle. Aus: \cite{winkler-seccloud-11}}
\label{figure:Zugriffskontrollmodelle}
\end{figure}

\subsection{Verchl"usselung f"ur Data in Motion}\label{sec:datensicherheit:verchlusselung fur Data
in Motion} Die Ziele der Verschlüsslung von Daten in Bewegung (Data in Motion) sind die Daten vor
Manipulaion zu schützen, ihre Integrität zu wahren und die Vertrauenswürdigkeit zu erhalten. Es soll
folglich keinem anderen als dem Sender und Empfänger, also bsp. jemand der die Daten während des
Transports abgreift, möglich sein, den Daten einen Sinn zu geben, noch sie zu verändern.
Um dieses Ziel zu erreichen, ist die Standardlösung die Nutzung von Verschlüsselung kombiniert mit
der Authentifizierung der Kommunikationspartner, um die Daten sicher in oder aus der Cloud zu laden.
Die Verschlüsselung der Data in Motion verbirgt also die Informationen der Daten während des
Trnaports über das Netzwerk, von einem Speicher zu einem Server und zurück.
Für diese Art der Verschlüsselung gibt es verschiedene Standards, wie Secure Sockets Layer
(SSL), Transport Layer Security (TLS) und Secure Internet Protocol (IPSEC).
Für die Authentifizierung der Verbindung wird meist eine PKI (Public-Key-Infrastruktur) genutzt, und
für die Verschlüsselung der Transportdaten ein symmetrischer Verschlüsselungsalgorithmus.
Am weitverbreitesten ist heutzutage die Nutzung einer sicheren Verbindung für die
Transportdaten zwischen Client und Servers mittels Nutzung des SSL Standards in Kombination mit RSA,
RC4, DES oder des Diffie-Hellmann Algorithmus.
Folglich unterscheiden sich die Maßnahmen zur Sicherung von bewegten Daten im Cloud-Umfeld nicht von
den bekannten Verfahren, die allgemein für eine sichere Kommunikation eingesetzt werden.

\subsection{Verschl"usselung f"ur Data at Rest}\label{sec:datensicherheit:verschlusselung fur Data
at Rest}
Die Verschlüsselung der ruhenden Daten (Data at Rest) ist eine Kernkomponente für die
Datensicherheit in einer Cloud-Umgebung. Denn die Verschlüsselung der Daten während ihres
Transports (Data in Motion) schützt nicht vor einem Angriff auf die Daten an ihrem Endpunkt.
Fakt ist nun mal, das die meisten Angriffe auf die Endpunkte, wo die Daten langfristig gespeichert
werden, stattfinden und nicht während des Datentransports.
In Anbetracht dieser Tatsache befinden wir uns in einer unangenehmen Situation. Denn auch wenn die
Verschlüsselung während des Transports (Data in Motion) mittlerweile weit verbreitet ist,
trifft dies auf ruhendes Daten (Data at Rest) heutzutage meist noch nicht zu, auch wenn
sicherheitsbewusste Administratoren involviert sind.
Ziel ist es folglich, die ruhenden Daten, in Form von Dateien im Dateisystem,
Datenbanktabellen in der Datenbank oder Raw-Daten in Blöcken in der SAN-Umgebung, mittels
Verschlüsselung zu schützen.

Es gibt verschiedene Ansätze, wie eine Sicherung der ruhenden Daten umgesetzt werden kann.
Diese basieren auf der Verschlüsselung der Daten auf verschiedenen Ebenen (Abbildung
\ref{figure:layered_data_security}): die Verschlüsselung der Daten durch eine Anwendung auf
Applikationsebene (Application Layer), die Verschlüsselung von Datei/Verzeichnissen
auf Datei/Verzeichnisebene (File/Directory Layer) und das Verschlüsseln von ganzen
Laufwerken auf Hardwareebene (Device Layer).
Auf diese verschiedenen Verschlüsselungsschichten wird im folgenden detaillierter eingegangen.

\begin{figure}[h]
\centering{
\scalebox{0.9}{\includegraphics{./img/layered_data_security.jpg}}}
\caption[Ebenen der Datensicherung]{Ebenen der Datensicherung. Basierend auf: \cite{sdar-TATA-07}}
\label{figure:layered_data_security}
\end{figure}

\begin{description}
\item[Anwendungs basierte Verschl"usselung] Bei dieser Art der Verschlüsselung werden die Daten,
also wie Dateien und Verzeichnisse, von der eingesetzten Software für den Anwender transparent
verschlüsselt. Folglich regelt die Anwendung nach einmaliger Konfiguration selbstständig die Ver-
und Entschlüsselung der von ihr verwendeten Daten.
Der Nutzer hat keinen Einfluss darauf und bekommt dies während der Arbeiten nicht mit. Es geschieht
also Endbenutzertransparent.
\item[Datei basierte Verschl"usselung] Diese Ebene erfordert die Kenntniss des Anwender über seinen
Datenbestand und über Verschlüsselungsmöglichkeiten. Denn es werden einzelne Dateien individuell
verschlüsselt. Also hat der Anwender die volle Kontrolle und Verantwortung darüber, welche Dateien verschlüsselt
werden und mit welchem Algorithmus.
\item[Verzeichnis basierte Verschl"usselung] Hierbei werden Verzeichnisse/Dateisysteme in Form von
Containern verschlüsselt.
Die Verschlüsselung auf Verzeichnis/Dateisystemebene bringt einige Vorteile wie Transparenz für
Anwender und Anwendungen, Flexibilität des Schlüssel-Management und der Zugriffskontrolle, gute
Leistung und Schutz vor einer Reihe von Angriffen.
Separate Schlüssel können verwendet werden, um verschiedene Objekte des Dateisystems, die
anderen Nutzern freigegeben werden, zu schützen, oder aber um verschiedene Sicherheitsebenen oder
Kategorisierungen von sensiblen Daten zu realisieren. 
\item[Laufwerks basierte Verschl"usselung] Diese auch als Full Disk Encryption bezeichnete
Verschlüsselung ist die unterste Ebene auf der Daten verschlüsselt werden können. Denn alle Daten
eines Laufwerks -- inklusive des Betriebssystems, der Programme, der Programmdaten und der
Nutzerdaten -- die auf dem Laufwerk liegen, werden verschlüsselt. Die Verschlüsselung findet folglich
in dem Laufwerks-Controller statt, sodass alles auf dem Laufwerk verschlüsselt ist. Wenn die Hardware dies
unterstützt, ist es eine einfache Methode Datensicherheit zu implementieren, die dem Anwender
gegenüber transparent ist. Weiter bietet die Verschlüsselung in Hardware oft Datenkompression.
Da die Speichermedien die Verschlüsselungsaufgabe bewältigen ist eine Änderung der bestehenden Daten-Infrastruktur 
nicht erforderlich. Auch wenn es einfach und kostengünstig zu implementieren ist, um statische und archivierte Daten zu sichern, so ist
die Sicherheit doch auch davon abhängig, wie die Daten zu dem Speicher übermittelt werden. Sollte dies
in unverschlüsselter Weise geschehen, bringt auch die sichere Speicherung der Daten keinen
Sicherheitsgewinn. Weiter ist diese Methode anfällig, wenn es zu Laufwerks Fehlern kommt, in einem
solchen Fall ist die Verfügbarkeit aller enthaltenen Daten gefährdet, wenn kein Backup vorhanden
ist.
\end{description}


\subsection{Cloud Lock-In}\label{sec:datensicherheit:Cloud Lock-In}
Ein großes Problem in Bezug auf die Verfügbarkeit von Daten bei der Nutzung eines Cloud Service ist
das sogenannte Cloud Lock-In. Grundsätzlich geht es dabei um die Frage, was passiert, wenn die eigenen Geschäftsprozesse abhängig von einem Cloud Service werden.
Das Problem, das sich nämlich ergibt, ist, dass sobald sie von den Dienstleistungen eines
Cloud-Anbieter abhängig werden, es wegen einer Reihe von technischen Gründe äußerst schwierig wird,
den Anbieter zu wechseln.
Ein Cloud Lock-In Beispiel wäre:  Ein Unternehmen nutzt einen bestimmten öffentliche CSP-Dienst
als Customer-Relationship-Management-Tool. Dieser Dienst wird verwendet, um alle Kundendaten des
Unternehmens zu verwalten. Das Unternehmen investiert also Zeit Regeln und Reporting-Routinen für
die Nutzung des Service zu implementieren. Der Dienst wird also primäre Reporting-Engine für
Kundendaten des Unternehmens. Wenn dieser Dienst nun proprietäre Formate oder APIs nutzt, so besitzt
der Service-Abonnent nichts weiter als die Daten, die ihm der Dienst liefert.


Entscheidet sich der CSP den Dienst einzustellen, so steht der Service-Abonnent vor dem
Problem, dass seine internen Prozesse auf diesen einen Dienst und seine proprietären Formate oder APIs
abgestimmt sind und somit von diesem abhängig sind. Somit ist es dem Service-Abonnenten
möglicherweise nicht möglich, sein Tagesgeschäft aufrecht zuerhalten. In diesem Fall wäre die
Verfügbarkeit seiner Daten nicht gewährleistet. Somit steht das Unternehmen möglicherweise
vor ernsten Herausforderungen bei der Migration seiner Daten, um einen Ersatz-Service zu finden.


\paragraph{Metadaten} $\;$ \\
Eine weitere Frage in Bezug auf das Cloud Lock-In Szenario ist, was passiert mit den Daten eines
Kunden, wenn der Dienst beendet wird? Wer hat dann womöglich Zugriff auf die Daten.
Weiter ist es eine Tatsache, dass wenn ein Dienst über längere Zeit genutzt wird, garantiert
eine nicht geringe Menge an Daten einfach durch die Nutzung des Dienstes entsteht, die sogenannten
Cloud-Metadaten. Was passiert folglich mit diesen Daten.
Metadaten sind einfach Daten über Daten, oder genauer gesagt sind es Highlevel-Informationen über
solche Dinge wie: Wo die Daten herkommen, von wem welche Operationen gegen sie durchgeführt wurden,
und welche Änderungen vorgenommen wurden.
Cloud-Metadaten können aber auch andere wertvolle Informationen enthalten wie die Beziehung von
Nutzern zu bestimmten Daten oder Dateninhalten. Solche Informationen können in einer SaaS Lösung im
Laufe der Zeit durch die CSP-Software entstehen.
Nachdem nun kurz erläutert wurde, was Metadaten sind, zurück zu der Frage, was passiert mit den
Metadaten, wenn der Teilnehmer entscheidet, die Nutzung des Dienstes zu beenden.

Während der Planung und Einführung der Nutzung eines Cloud-basierten Dienstes übersehen Kunden oft
Fragen wie, was passiert, wenn sie so abhängig von dem Dienst werden, dass es unmöglich ist, diesen zu
ersetzen bzw. zu wechseln.
Dabei kann eine Abhängigkeit von einem Cloud-Dienst erhebliche Auswirkungen auf das Geschäft des
Kunden haben. Unternehmen, die einen Cloud-Dienst in Anspruch nehmen, haben möglicherweise nicht die
Absicht, ihn je zu verlassen. Aber es kann Umstände geben, wo die Beendigung des Nutzens eines
Dienstes nötig ist. 
Zum Beispiel, was passiert, wenn der Cloud-Anbieter seinen Dienst einstellt oder er sein
Geschäftsmodell ändert? Beispielsweise hat Facebook eine signifikante Veränderung von einem privaten
Geschäftsmodell zu einem offeneren Modell durchgeführt.

\paragraph{Verhindern des Cloud Lock-In} $\;$ \\
Da das Cloud Lock-In ein allgemein bekanntes Problem ist, bieten glücklicherweise viele der großen
öffentlichen Cloud-Services-Provider ihren Kunden die Möglichkeit nicht nur die Daten, sondern auch
die Metadaten zu exportieren.
Jedes Unternehmen sollte daher, diese Exportmöglichkeit als wichtiges Feature eines CSP sehen.
Bei der Einführung eines Cloud-Dienstes, von dem das Unternehmen möglicherweise abhängig werden könnte, ist darauf zu achten, dass der gewählte CSP solch eine Exportfunktion bietet. Damit keine unwiderruflichen Abhängigkeiten von diesem CSP entstehen können. Denn es ist unrealistisch anzunehmen, das immer ein kompatibler Dienst bei einem CSP
gefunden werden kann.

Wenn es keinen Mechanismus gibt, die eigenen Daten zu exportieren, führt dies zu einer
geschäftsschädigenden Situation mit unter Umständen nicht absehbaren Kosten. 
Jedoch ist das bloße Vorhandensein einer solchen Exportfunktion allein nicht die einzige
Anforderung, die bei der Auswahl des CSP eine Rolle spielt. Wie die Daten nach dem Export zugänglich
und nutzbar sind ist genauso wichtig. Wenn die Daten in einem proprietären Dateiformat exportiert werden,
ist es möglicherweise nicht möglich, die Daten verständlich zu analysieren und in ein anderes
Format zu überführen. Denn genauso wichtig wie der Export ist es, dass die Daten in das System eines
neuen CSP importiert werden können.
Es ist also wichtig all diese Dinge zu beachten und im Vorfeld zu klären, wenn beabsichtigt wird,
den Cloud-Service Provider zu wechseln.

Beispiele wie das Cloud Lock-In Problem bei drei großen CSP's konkret behoben wird:

\begin{description}
\item[Salesforce.com] bietet seinen Abonnenten die Möglichkeit, einen kompletten Export aller Daten
einer Abonnenten-Instanz zu generieren. Bei manchen Service-Angeboten ist die Exportfunktionalität
enthalten. Sie kann aber bei allen Angeboten gegen eine zusätzliche Gebühr als Option hinzugebucht
werden. Exportiert wird in das CSV-Format. Die Rohdaten für jedes Salesforce Objekt werden in einer
separaten Datei gespeichert. Dem Kunden werden all seine Objekte in Form der CSV-Dateien,
gepackt in einer ZIP-Datei zur Verfügung gestellt. Dies kann auch per Script automatisch
erfolgen und kann somit zur Erstellung eines Backups dienen. Wichtig ist auch zu wissen, dass mehrere Cloud Service Provider in der Lage sind mit diesen exportierten CSV-Dateien umzugehen. Soll
heißen, sie sind in der Lage diese automatisch zu importieren und zu überprüfen. 
Folglich bietet Salesforce eine praxistaugliche Möglichkeit, das Cloud Lock-In zu verhindern.
\item[Google] betreibt eine eigene Abteilung, die sich um die Lösung dieses Problems kümmert, die
sogenannte Data Liberation Front. Die Data Liberation Front definiert ihr Ziel wie folgt:
\begin{quote}
Users should be able to control the data they store in any of Google's products.  Our
team's goal is to make it easier to move data in and out.\footnote{http://www.dataliberation.org/}
\end{quote}

Ein Beispiel für die Bemühungen  Googles ist bei Google Docs zu sehen.
Google Docs kann als ein Repository für Dokumente der Textverarbeitung, Tabellenkalkulationen und
mehr eingesetzt werden, auf das viele Benutzer (oder Organisationen) Zugriff haben können. Als solch
ein Repository ist es natürlich wichtig, dass alle Dokumente sehr portabel sein sollten. Google hat
daher eine Funktion integriert, die den einfachen Export von allen bei Google gehosteten Dokumenten
mit wenigen Klicks ermöglicht. Weiter bietet Google die Möglichkeit die Dokumente nicht einfach
nur zu exportieren, sondern dies auch noch in unterschiedlichen Formaten, wie Microsoft Office
Formate, Open Office Formate, Adobe PDF und weitere.
\item[Amazon] bietet auch eine Exportfunktion für seine Webservices, insbesondere den Elastic Compute
(EC2)-Dienst. Aber auch für die anderen Cloud-Services, wie für die
Datenspeicherung, Datenbank-Computing und einige andere Dienstleistungen wird der Export von Daten
angeboten. Die Herangehensweise für das Problem der Import/Export-Funktion unterscheidet sich von
den anderen Anbietern. Amazon geht davon aus, dass es sich um so große Datenmengen handelt, dass
ein Download dieser Daten aufgrund der Menge nicht in realistischer Zeit umsetzbar ist.
Kunden können daher eine  tragbare Festplatte vorbereiten und online einen Import/Export Job in
Auftrag geben. Nun muss die vorbereitete Festplatte an eine von Amazon vorgegebene Adresse
gesendet werden und die Daten-Migration wird durchgeführt.
\end{description}

Es gibt heutzutage aber auch schon Unternehmen, die sich auf Lock-in Fragen in Bezug auf
öffentliche Cloud-Service-Provider spezialisiert haben. Ein Beispiel ist Backupify\footnote{www.backupify.com}. 
Die primäre Dienstleistung solcher Unternehmen bietet dem Kunden die
Möglichkeit der automatischen Sicherung und Archivierung all seiner Daten eines Cloudservices.
Backupify unterstützt bisher jedoch nur die automatisierte Sicherung und Archivierung von Daten aus
Facebook, Flickr, Twitter und Google Docs. Es ist nur eine Frage der Zeit bis andere Unternehmen
solche Dienstleistungen auch für Enterprise Cloud Services anbieten werden.


\subsection{Zusammenfassung}\label{sec:datensicherheit:Zusammenfassung}
Die Sicherheitsbedenken rund um die Speicherung von Daten in einer Cloud sind zunächst nicht einmal
nicht groß anders im Vergleich zu der Speicherung von Daten innerhalb eines Unternehmens.
Aber es ist auch nicht so, das man sagen kann, die Risiken, welchen die Daten ausgesetzt sind, wären
die gleichen, denn es handelt sich immerhin um zwei sehr unterschiedliche Umgebungen. Letztlich können
die Bedenken aber in die folgenden drei Schlüsselbereiche aufgeteilt werden und dann
entsprechende Maßnahmen ergriffen werden um die Bedenken abzubauen:
\begin{itemize}
  \item \textbf{Identifizieren der Daten und Anwendungen, die in einer Public Cloud
  gespeichert werden sollen.} Denn zu wissen, welche Daten in der Cloud sein werden, ist schon
  ein großer Schritt um Datensicherheit umzusetzen. Die Antwort auf die doch simpel erscheinende Frage ist jedoch nicht offensichtlich und lässt weitere Fragern aufkommen, beispielsweise die generelle Frage nach der Datenherkunft, die in
  einer Cloud gespeichert werden sollen. Damit einher geht die Frage, ob Daten, die in der
  Cloud verändert oder gar dort erstellt wurden, genauso wichtig sind, wie die Originaldaten. 
Metadaten sollten ebenfalls identifiziert und geschützt werden.
Genauso wichtig ist es zu wissen, wo die Daten in der Cloud letztlich physikalisch gespeichert sind und
welche Gesetze dort gelten. Dies ist besonders wichtig, wenn es sich um regulatorische, behördliche
Daten handelt.
\item \textbf{Verhindern eines Cloud Lock-In.} Um dies zu gewährleisten, ist es nötig das sich von
vornherein mit dem Thema auseinander gesetzt wird und Strategien entwickelt werden um
dieses Problem zu vermeiden. Dazu gehört beispielsweise, bei der Auswahl eines CSP schon zu
schauen, was für Exportmöglichkeiten dieser bietet und welche Formate dafür genutzt
werden, um später sicherstellen zu können, dass die Daten auch wieder bei einem anderen CSP in
vernünftiger Weise importierbar sind.
\item \textbf{Verstehen der verfügbaren Datenschutzoptionen.} Planen und umsetzen einer soliden Strategie für
den Schutz der sensiblen Daten. In der Cloud sind, wie auch bei der Sicherung von Daten in traditionellen IT-Umgebungen, Verschlüsselung und Authentifizierung Schlüsselfaktoren für die Umsetzung und Ge\-währ\-leis\-tung von Datensicherheit. Wichtig in Bezug auf die Nutzung von Verschlüsselungstechniken
ist zu wissen, welche Art wann und vor allem wie eingesetzt werden muss, damit auch wirklich der
erhoffte Schutz geboten wird. Auch ist es wichtig ist zu wissen wie Daten sicher gelöscht werden, und wie lange einzelne Backups des CSP vorgehalten werden. 

In der Cloud sind, wie auch bei der Sicherung von Daten in traditionellen IT-Umgebungen, Verschlüsselung und Authentifizierung Schlüsselfaktoren für die Umsetzung und Gewährleistung von Datensicherheit